fix: multi-table DELETE+LIMIT syntax error and inaccurate index comment in cleanup_orphan_stats - #115

Two issues in the batched cleanup_orphan_stats rewrite and one misleading comment introduced by the previous perf commit.

Bug fix: multi-table DELETE with LIMIT is invalid MySQL/MatrixOne syntax

DELETE alias FROM t1 LEFT JOIN t2 … LIMIT n is rejected at runtime — MySQL forbids ORDER BY/LIMIT on multi-table deletes. Every other batched DELETE in the file is single-table for exactly this reason.

Replaced with the standard two-step pattern used elsewhere:

-- Step 1: SELECT up to 1000 orphan IDs (LIMIT valid on SELECT)
SELECT s.memory_id
FROM mem_memories_stats s
LEFT JOIN mem_memories m ON s.memory_id = m.memory_id
WHERE m.memory_id IS NULL
LIMIT 1000;

-- Step 2: single-table DELETE by PK — no LIMIT restriction
DELETE FROM mem_memories_stats WHERE memory_id IN (?, …);

mem_memories_stats has memory_id as its PRIMARY KEY (one row per memory), so the SELECT never returns duplicates and the loop terminates correctly.

Comment fix: idx_memories_user_observed scope

The original comment claimed the index also accelerates archive_stale_working. It doesn't — that function uses TIMESTAMPDIFF(HOUR, observed_at, NOW()) > ?, which wraps observed_at in a function and prevents a B-tree range scan. The index only helps health_capacity()'s direct range predicate observed_at >= NOW() - INTERVAL 30 DAY. Comment corrected accordingly.

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.